Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/rreq/rreq-minutes-90feb.txt

Text File | 1993-02-17 | 15.2 KB | 415 lines

CURRENT_MEETING_REPORT_



Reported by F. Baker/Vitalink, S. Senum/Network Systems
Corporation, P. Almquist/Consultant and J. Forster/cisco Systems



MINUTES


The IETF Router Requirements Working Group is a new working which met
for the first time during the IETF meeting in Tallahassee.  The IESG
formed this working group to draft a standard for Internet IP routers
which will be up to date and which will match the level of clarity and
completeness achieved in the recent Host Requirements RFC's (RFC1122 and
RFC1123).  The group intends to submit its document to the Internet
standards process in early 1991.  If it is accepted, it will replace
RFC1009, the current standard for Internet routers.

The group held three half-day meetings in Tallahassee.  Topics discussed
fall into four basic categories:

  1. Group startup activities.  This included such things as discussing
     the charter and the schedule and agreeing on exactly what is the
     task to be performed.
  2. Creation of an outline.  The co-chairs drew up a strawman outline
     for the document in advance of the meeting.  The group adopted this
     outline with some modifications.
  3. Distribution of writing assignments.  Many of the group members
     agreed to draft sections of the document before next meeting,
     tentatively scheduled to be a videoconference in late March, 1990.
  4. Initial discussion of technical issues.  Close to half of the
     meeting was devoted to discussion of what the document should say
     about a variety of issues, such as ARP and IP option support.

UPCOMING SCHEDULE

   o February 6-9, 1990:  IETF meeting, FSU
   o Late March, 1990:  video conference
   o May 1-4, 1990:  IETF meeting, PSC
   o mid-June, 1990:  video conference
   o July 31-August 3, 1990:  IETF meeting, UBC
   o August 15, 1990:  first Internet draft version submitted
   o mid-September, 1990:  video conference
   o early November 1990:  IETF meeting, Washington University
   o December 3, 1990:  second Internet draft version submitted
   o mid-December, 1990:  video conference
   o January 15, 1991:  final Internet draft version submitted
   o early February 1991:  IETF meeting, NCAR
   o February 15, 1991:  final version submitted to IESG and RFC editor

                                   1






MINUTES - 2/6/89

Introduction:

The charter of the working group calls for a descendant of the Router
Requirements Document (RFC 1009), modelled on the general format and
spirit of the Host Requirements Document (RFCs 1122 and 1123).

The initial submission is an outline, which may be reorganized, and will
be fleshed out by the submissions of a number of authors.  There is also
a proposed schedule for the work to be done, culminating in a final RFC
in early 1991.

In support of this, a commitment is requested and required of all
participants, to expedite the delivery of this document.

Charter:

Several documents feed into this process:

   o RFC 1009 Router Requirements
   o RFC 1122 Requirements for Internet hosts - Communication Layers.
   o RFC 1123 Requirements for Internet hosts - Application and Support.
   o Many RFCs included by reference

There was general agreement on the charter as written, with the
suggestion of some extra wording on the general subject of
Interoperability.

Presentation Style:

The IESG proposes a document much like the Host Requirements Document,
especially in the sense of flagging sections as 'required' and
'optional', flagging requirements stated in those sections as 'must
[not]', 'should [not]', and 'may', and the concepts of 'full' and
'conditional' compliance.  Compliant Routers (full or conditional)
should interoperate by definition.  This is accepted as the initial
strategy, and the usage of those terms is intended to be as much like
its predecessor as possible.

By way of example, ARP is generally an optional protocol, and should be
stated as optional; However, if Ethernet interfaces are implemented, ARP
implementation is required, and certain operational experience since the
original RFC was written must be accounted for.

A postscript version of the document may come into existence; however,
to facilitate world wide ease of access to the document, a text version
WILL be available.

A number of points that came out in a general discussion (not all of
which represent any kind of concensus of the group):

                                   2






Vendors need the document in order to know how to implement a
universally acceptable product, and Network Managers need to one to
specify in RFQs.  Net Managers ALSO need a document indicating how the
features of a compliant Router are intended to be used.  These are not
necessarily the same document.

We need a Multi-protocol Router Document, although this is technically
outside the working group's charter.  This document should explicitly
not preclude alternative architectures, and will attempt to state
requirements that will allow multi-protocol routers to be compliant.

There needs to be a section regarding global traffic engineering.
Congestion Management is a special case of traffic engineering.  There
will be a discussion of Congestion Management, especially Fair Queuing,
but the details may be referred to another working group.

Verbiage needs to be clear and consistent, and consistent (where
relevant) with the Host Requirements Document.  A Glossary may be
helpful.

IP Multicast needs to be dealt with on a MAC by MAC basis.

The 'All Subnets' Broadcast, although required by RFC1009, is probably
not implemented by anyone, and its originally intended function is
probably better served by IP multicast.  Also, the all subnets broadcast
would be dangerous if implemented, since hosts which are unaware that
the network is subnetted may generate packets that look like all subnets
broadcasts unintentionally.

There seem to be two options for dealing with the all subnets broadcast.
The first is to require it, since it would not be useful unless widely
enough implemented that applications could reasonably expect it to work.
If we do that, we should also specify an/the agorithm for the flooding.
An alternative is to declare the entire notion of the all subnets
broadcast to be obsolete.  Philip Almquist will write an RFC suggesting
the latter.

Line protocols recommended by this document must have some sort of
protocol discriminator field.  Point-to-Point and ISO 7776/8880(3) both
have this.

Apple Localtalk has an RFC in progress.

X.25 protocol:


   o there are several alternatives for discriminating between protocols
     on X.25 - most notably using a discrimination octet on each packet
     and running separate Virtual Circuits by protocol, TOS, destination
     tuple.
   o several de facto standards exist:  DDN 'basic' and 'standard',
     Blacker, and European.

                                   3






ARP needs to be fairly closely spelled out, especially regarding Proxy
ARP and ARP Response to IP Multicast Address.  (See minutes from 2-7-90)

Hyperchannel and ARCnet have inadequate current interest to justify a
section in the document.

There needs to be a precedence statement indicating that this document
takes precedence over the base RFCs for each feature, and over the Host
Requirements Document in certain cases.  Writers are expected to
reference the Host Requirements Document regularly; in the draft
versions, please include the relevant text to simplify reviewer's
cross-referencing; this will be removed from the final draft.

The Objective (writers take note!)  is to specify the external
characteristics of an Internet standard Router, not the algorithms it
uses to implement that behavior.  For example, this document should
state that the ARP cache should lose track of information about hosts
that disappear from the network, and should do so reasonably
expeditiously.  Whether this depends on internal timers 'popping', or on
entries being found to be invalid upon reference, or some other
algorithm, is not for this document to specify.

Routing Protocols:

Thou shalt not digress into religion, politics, or the correct standard
IGP! The IESG and IAB are expected to decide on the standard Internet
IGP, and this document should reference their decision.

EGP2 and BGP should be documented; EGP3 should not be.

Re:  Filters and Controls, the effects of these should be specified
without specifying the specific syntax or semantics.

Network Management:

By default, routers should allow public SNMP read access to at least the
subset of the MIB required for diagnosis of end-to-end connectivity
problems.  However, the manager of the router should be able to disable
the public access.  The security aspects of SNMP need to be examined in
more depth.

There needs to be universal read access to a subset of the SNMP readable
information, with significant control of the ability to write.  However,
attention should be given to the security aspects of SNMP readability.

Performance requirements should include or reference standard tests,
network stability under load, the forwarding and timely processing of
updates, and the priority (if any) those updates should enjoy.

There should perhaps be a vendor independent (potentially SNMP based)
user interface to all Routers.

                                   4






MINUTES - 2/7/90

Address Resolution Section

The day started out with a detailed discussion of ARP. Generally, people
seemed to feel that MAC-specific details of ARP should be discussed in
the relevant MAC layer sections, but a stand- alone section should cover
common ARP issues.  This section should be called Address Resolution,
and should also cover X.213/X.25 addressing issues (referencing the PDN
Working Group's work).

Several viewpoints were brought out on most of the following points, but
these represent the endpoints of several (sometimes simultaneous)
discussions:

   o Routers are generally triggered to ARP by a message which needs to
     be forwarded to a currently unknown system.  While the impact of
     not holding the triggering packet is not great, a Router 'should'
     hold and re-transmit a small number of such messages for a limited
     period of time.
   o The ARP procedure calls for periodic refreshing of the ARP
     database, potentially using a broadcast in case the system has
     changed its MAC address.  Generally, the first refresh attempt
     should be a unicast to the last known MAC address.
   o Proxy ARP is useful in circumstances where the Network
     Administrator can't or doesn't choose to advise his hosts of the
     local subnet architecture, or where the architecture is ambiguous,
     as in a multi-rail FDDI with some single rail systems on each ring.
     It may be viewed as a simplistic Router Discovery Protocol or a
     subnet disambiguator.  Use of Proxy ARP in normal networks,
     however, is discouraged.  Routers 'may' provide it, it 'must' be
     configurable, it 'must' be disabled by default, and 'should' be
     configurable by interface.
   o Systems 'must not' respond to an ARP for any recognizable Broadcast
     or Multicast address (Class D, 0.0.0.0, 255.255.255.255, Network or
     Subnet variants).
   o Routers 'should' emit an ARP request for their own address upon
     startup, and log an error in the event that anyone responds.
     Similarly, during normal operation, any ARP Request or Response
     sourced from a Router's IP address and indicating a Hardware
     Address other than the Router's should be logged.
   o In the event that a Router's Hardware Address is changed, it should
     broadcast a gratuitous ARP reply advising the world of the event.
     However, on startup in a multiprotocol Router, this should NOT
     occur when the Router changes from its native address to its
     protocol-specific MAC address; instead, the Router should wait for
     the completion of the configuration sequence to send its initial
     ARP reply.

Internet Protocol Section

Routers 'must' implement options:


                                   5






   o see RFC 1009 in case we forgot something
   o Loose Source Route and Record
   o Strict Source Route and Record
   o Record Route
   o Standard Security Option ('must' be first in option list)
   o Timestamp
   o NOP
   o End of List

Routers 'may' implement

   o Extended Security Option
   o Detection of combined or multiple Strict/Loose/Record Route
   o MTU Options

Routers 'may' ('should not'?)  implement obsolete IP options

   o SATNET Stream ID
   o Revised Security Option

Routers 'must not'

   o Combine or multiply Strict/Loose/Record Route Options

There are some computational order dependencies:

   o most options only make sense after the forwarding decision has been
     made.
   o Strict and Loose Source Route apply BEFORE the forwarding decision,
     but only in systems addressed by the Destination IP Address.
   o Routers must fragment traffic.  There was some feeling that the
     Router should make the first n-1 fragments the size of the MTU, and
     let the last be the modulus, and some feeling that the fragments
     should all be approximately the same size (we learned later that
     the currently proposed MTU discovery mechanism requires the first
     choice - ed).
   o Time to Live must be decremented on each hop.  No vendor present
     decrements in seconds, but there was some feeling that decrementing
     by two when presenting traffic to a congested queue was doable and
     not all bad.
   o Routers should recognize and correctly deal with all recognized
     broadcast addresses (Class D, 0.0.0.0, 255.255.255.255, Network or
     Subnet variants) at the same time; configuration parameters deal
     with what the Router emits, not what it recognizes.
   o Routers 'must' not route traffic directed to a MAC broadcast or
     multicast address back to the same MAC. Routers 'should' not
     forward traffic directed to a MAC broadcast or multicast address at
     all.

Initial Writing Assignments



                                   6






Fred Baker:          Address Resolution, ARP section

Art Berggreen:          Address Resolution, X.25/X.213 section

Steven Senum:          Hyperchannel, IP Options

John Hamner:          Time to Live

Stev Knowles:          Fragmentation and Re-assembly

Stev Knowles:          Treatment of IP Broadcast Addresses

Stev Knowles:          Glossary

John Veizades:          LocalTalk

Mike Ride, Jeff Burgan, Roxanne Streeter:         Internet IGPs, IP
            Filtering, IGP Translation

Steve Willis:          IEEE 802 LANs, Ethernet

Martin Gross:          ICMP

Philip Almquist:          Introduction

Bill Melohn and Fred Baker:          Serial Line Protocols

Jeff Burgan:          External Gateway Protocols

Jim Forster:          Variable Length Subnet Masks

Steve Willis:          SNMP

Philip Almquist:          Forwarding

Jim Forster:          Congestion Management


MINUTES - 2/8/90

Additional requirements discussed:

   o Ignore reserved bits in IP packets
   o Router should not require network services (like DNS) to boot (Jeff
     Burgan will write a section on this)
   o Specify that if a Routing Protocol is implemented, it must be fully
     implemented (must follow appropriate RFC)
   o Discuss multiple subnets (addresses) on an interface.
   o Require SNMP for a router
   o Performance requirements (like IS-IS) (Steve willis will write a
     section on this)

                                   7